IBIS Macromodel Task Group Meeting date: 19 November 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the November 12 meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: BIRD198.1: Randy noted that he had met with the authors at the Tokyo summit. He noted that their presentation at the summit had not contained any new information. It was a summary of their proposal and the latest feedback from ATM. The authors had stated that they were happy to be working with us. Arpad asked if there had been any concerns about miscommunication via email. Randy said they had discussed some of the differences in communication style, but that they seemed satisfied with the communication via email since it was difficult for them to join regularly scheduled ATM meetings. Randy noted that the authors said they were finalizing a response to the latest ATM comments, and we can expect that within a few weeks. Randy noted he had not discussed the specifics of the ATM counter-proposal with them, and we could wait for their reply. Bob asked if any of the authors planned to attend DesignCon. Randy said that some of the authors will attend. BIRD197.6_draft_1: Bob introduced his new draft containing editorial revisions to BIRD197.5. The substantive changes were the addition of language stating that the application scenarios were tied to the particular Example: that was given. In addition, Bob had added an introductory sentence to both application scenarios (1 and 2). Walter and Ambrish stated that the new language tying the application scenarios to the Example: was incorrect. They were not tied to that particular Example:. Walter agreed with Bob's new introductory sentences, but suggested that for both 1 and 2 the introductory sentence should be combined with item a. Walter and Ambrish noted that the value of the DC_Offset parameter provided in the .ami file is nothing more than a place holder that must be overridden by the EDA tool, i.e., the EDA tool must provide a value. Bob took an AR to further update the draft. Enabling Back-channel in Statistical Mode: Walter reviewed his "DDR5 DQ Write Protocol" presentation. Walter noted that he and Wei-hsing had discussed the issues off-line since the last meeting, and he thought they both agreed on the conclusions. slide 2 - Overview - Iterative AMI_Init() (or AMI_Impulse() or AMI_GetWave()) vs. Proxy approach. slide 3 - Walter's Iterative Methods - Iterate AMI_Init(), AMI_GetWave() or AMI_Impulse(). - Implementation details differ for each. - All three use a BCI parameters branch. slide 4 - (BCI ...) Branch for DDR5 DQ Write protocol - Walter thinks ATM is leaning toward using AMI_Init(). - AMI_Init() function would maintain a history file. - IBIS need only document the (BCI ...) parameter trees that the Tx writes and the and Rx writes. slide 5 - Tx (BCI ...) Output proposal - Sequence #, Tap weights, gain, and state of training. slide 6 - Rx (BCI ...) Output proposal - Sequence #, state, BER (contour), Eye_Height, Eye_Width, Eye_Area slide 7 - That's all that's required - Protocol would include a definition of the Eye_Area calculation. - Vendors mays want to add more (Jitter, Noise, VrefDQ, other metrics, etc.) slide 8 - AMI_Init() vs. Proxy approach - Deciding factor may be that it's easier to satisfy the requirement that any vendor's Tx will work with any other vendor's Rx with the iterative AMI_Init() approach. - Proxy approach is a great idea for allowing a specific Tx and Rx .dll to define a private protocol so the Rx can optimize the Tx or vice versa. However, it may be hard to define it in such a way that interoperability of models from different vendors is assured. Arpad asked if Walter was saying the Proxy method would only work if the Tx and Rx are done by the same vendor. Walter said he wasn't saying that, but it would be difficult for the spec. to define the communication for a Proxy approach. Arpad noted that Walter's proposal required some modifications to the spec. So, he wondered if we could consider adopting some spec. changes to implement Wei-hsing's Proxy approach and see which was easier. Wei-hsing noted that he had not introduced the Proxy approach with the intent of making an either-or decision. He did not intend it to be mutually exclusive with Walter's proposal. He shared the Proxy approach as a way in which a model developer could achieve back channel optimization in statistical mode without requiring the end user to update their tools to support new AMI features. Wei-hsing noted that Walter's approach would be easier for model makers once the EDA tools had adopted it. But, in the meantime, the Proxy approach could be used by a model maker to solve the problem using existing tools. Ambrish noted that, if interoperability was the primary concern, BIRD147 had addressed this issue for time-domain flows. Ambrish suggested that extending AMI_GetWave() so that it could be passed an IR might be the least disruptive way to meet the need for BCI in statistical mode. Walter said the biggest issue with using BIRD147 and AMI_GetWave() was that it relied on file I/O. Walter said his new proposal with the (BCI ...) branch didn't rely on file I/O. Walter noted that the only reason Bob Miller (Avago) had changed BIRD147 to use file I/O was that their original plan to overload the AMI_parameters_out argument to pass parameters in to AMI_GetWave() had not been accepted by others. He noted that any plan to use AMI_GetWave() for statistical BCI would need file I/O or some other way to pass parameters in to AMI_GetWave(). Arpad noted that he didn't think the group had really decided against adding a new AMI_Impulse() function, so it wasn't clear that we were leaning toward using AMI_Init() instead. Walter said he preferred an AMI_Impulse() be added, but he could work with AMI_Init(). Walter said he hoped to get a BIRD for this approved in Q1 of 2020, with working models to follow by Q3 or Q4, and working tools within a year. He said there are IP vendors who want this functionality, and it's not only for DDR5. Arpad asked if we should schedule a vote for the next meeting. Several attendees said they would not be able to attend the next meeting. Walter suggested we continue discussion at the next meeting and hold a straw poll at the meeting on December 3rd. Walter suggested we might first have people vote on their preference (Init, Impulse, GetWave, or Proxy), then have a final vote to choose between the two most popular choices in the first vote. Walter noted that adding a new AMI_Impulse() function might actually make it much easier in the future for someone to implement Wei-hsing's proxy approach. - Curtis: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. AR: Bob to refine the BIRD197.6 draft. ------------- Next meeting: 26 November 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives